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Beschreibung 

Verfahren zum Betrieb einer industriellen Steuerung 

5 Die Erfindung bezieht sich auf ein Verfahren zum Betrieb ei- 
ner industriellen Steuerung, insbesondere fur Produktionsma- 
schinen . 

Ferner bezieht sich die Erfindung auf eine industrielle Steu- 
10 erung zur Durchfuhrung des erf indungsgemaften Verf ahrens . 

Es ist heutzutage ublich, sowohl fur die speicherprogrammier- 
^|| bare Steuerung (SPS) als auch fur die Bewegungssteuerung (MC) 
jeweils unterschiedliche hierarchische Ablaufebenen zu model- 
15 lieren, denen Software-Tasks zur Steuerung des jeweiligen 

technischen Prozesses zugeordnet werden. Diese Tasks konnen 
Systemaufgaben erfullen, sie konnen aber auch anwenderpro- 
grammiert sein. 

20 Aus DE 197 40 550 Al ist es bekannt, dass Prozesssteuerungs- 
funktionalitaten der speicherprogrammierbaren Steuerungen 
"SPS" und Bewegungsfunktionalitaten von MC-Steuerungen in ei- 
nem einheitlichen konf igurierbaren Steuerungssystem integ- 
riert werden konnen. 

25 

\^ Diese SPS/MC-Integration geschieht in Form des Zusammenschal- 
tens von SPS- und MC-Steuerungsbaugruppen . Bei einer solchen 
Ausfiihrung der Integration wird aber keine optimale und effi- 
ziente Taskstruktur fur die Gesamtheit der Steuerungsauf gaben 

30 erreicht. Aufierdem werden bei dieser Art der Integration 

hauptsachlich die klassischen MC-Funktionalitaten, wie sie 
insbesondere fur Werkzeugmaschinen relevant sind, unter- 
stutzt. Anf orderungen an die Steuerung, wie sie aus dem Be- 
trieb von Produktionsmaschinen bekannt sind, werden durch 

35 diese Art des Zusammenschaltens von SPS- und MC-Steuerungs- 
baugruppen nicht optimal unterstiitzt. 
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Aus EP 0 735 445 A2 ist es bekannt, zum Betrieb einer Werk- 
zeugmaschine oder eines Roboters einen gesonderten Wartebe- 
fehl (WAIT) zu gebrauchen. Der hier beschriebene Wartebefehl 
(WAIT) unterstiitzt aber insbesondere die Steuerung von Pro- 
5 dukt ionsmaschinen noch nicht optimal. 

In der Anmeldung DE 19 93 19 33.2 wird vorgeschlagen, den 
Takt des Kommunikationssystems zwischen dem PC-System und den 
peripheren Geraten fur einen Wechsel zwischen einem Echtzeit- 

10 bet riebsprogramm und einem Nicht-Echt zeitbetr iebsprogramm 
heranzunehmen . Hier ist es aber die Aufgabe dieser Taktab- 
greifung aus dem Kommunikationssystem, in einem industriellen 
) Prozess einen moglichst reibungslosen Wechsel zwischen Echt- 
zeit- und Nicht-Echt zeitanwendungen stattfinden zu lassen. 

15 Bei dieser Ausgestaltung wird der Grundtakt aber nur aus dem 
Takt des Kommunikationsmediums abgeleitet und er wird nur fur 
den Wechsel des Betriebssystemmodus eines PC-Systems verwen- 
det . 

20 Der Erfindung liegt daher die Aufgabe zugrunde, fiir jeweils 
unterschiedliche Steuerungsauf gaben und unterschiedliche 
Randbedingungen bzw. Anf orderungen des zugrunde liegenden 
technischen Prozesses in einfacher Weise optimale Auspragun- 
gen einer industriellen Steuerung zu erstellen, die sowohl 
25 SPS- als auch MC-Funktionalitat zur Verfiigung stellt und so- 
^ mit auch fiir die Steuerung von Produktionsmaschinen geeignet 
ist . 

Diese optimalen Auspragungen werden prinzipiell zum einen 
30 durch ein einheitliches konf igurierbares Ablauf ebenenmodell 

fur die Steuerungs-Tasks der industriellen Steuerung erreicht 
und zum anderen durch Mechanismen (Wait_f or_Condition- 
Befehl) , die es einem Anwender ermoglichen, im Programmf luss 
auf beliebige Bedingungen zu warten und hoherprior zu reagie- 
35 ren. 
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Von diesem Ansatz ausgehend wird die oben genannte Aufgabe 
dadurch geldst, dass Mechanismen bereitgestellt sind, die es 
einem Anwender ermoglichen im Programmf luft auf eine beliebige 
Bedingung zu warten, wobei bei Erfulltsein der Bedingung der 
5 Programmf lufi unmittelbar fortgesetzt wird, bei Nichter f ullt- 
sein der Bedingung der Programmf lufi solange angehalten wird, 
bis das Erfulltsein der Bedingung festgestellt wird, wobei 
beim Warten auf das Erfulltsein der Bedingung die Prioritat 
der Bedingungsuberpruf ung im Vergleich zur aktuellen Taskpri- 

10 oritat erhoht wird. Durch diesen Mechanismus wird es ermog- 
licht, eine zusammengehorige und geschlossene Auf gabenstel- 
lung in einem Stuck Code eines Anwenderprogrammes auszudrii- 
cken, ohne dass weitere Mechanismen wie z.B. Event-Handler 
erforderlich sind. Ein Anwender kann somit in einem sequen- 

15 tiellen Programmablauf auf einer relativ niedrigen Priori- 
tatsebene einer "Motion Task" durch Programmkonstrukte in 
seinem Programmf luft (Anwenderprogramm) das Warten auf 
hochpriore Ereignisse formulieren, ohne in ein anderes Pro- 
gramm wechseln zu miissen. Dadurch wird einerseits in der 

20 Steuerung Verwaltungs-Overhead vermieden, was direkt die Sys- 
tem-Performance erhoht und andererseits aus programmiertech- 
nischer Sicht das Lokalitatsprinzip unterstutzt, wodurch z.B. 
das Debugging erleichtert wird. 

25 Der be^hriebene Mechanismus und der dazugehorige Befehl wer- 
den im weiteren als "wait_f or_condition" bezeichnet. 

Eine erste vorteilhafte Ausgestaltung der vorliegenden Erfin- 
dung liegt darin, dass nach dem Erfulltsein der Bedingung die 

30 folgende Programmsequenz bis zu einem expliziten Ende hoch- 
prior bearbeitet wird, wobei nach dem expliziten Ende der 
Programmsequenz die alte Taskprioritat wieder auf genommen 
wird. Dadurch wird eine hohe Deterministik in der Sequenz 
"Warten auf externes Ereignis" und der "Aktion, die nach die- 

35 . sem Ereignis folgt", z.B. Korrekturbewegungen bei einer 

Druckmarkensynchronisation, erreicht. Ein Anwender hat somit 
die Moglichkeit sich in seinen Programmen temporar auf eine 
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hohe Prioritatsebene zu legen und dabei deterministische Vor- 
gange leicht und elegant beschreiben zu konnen. Anwendungs- 
beispiele sind z.B. Druckmar kensynchronisation und schnelle 
Bewegungsstart (beispielsweise nach Flankenwechsel ) . 

5 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass fur die Formulierung der Bedingungen ProzeBsigna- 
le und/oder interne Signale der Steuerung und/oder Variablen 
aus Anwenderprogrammen verwendet werden . Dadurch ist es dem 
10 Anwender moglich, bei der Beschreibung der Bedingungen in ei- 
ner einheit lichen Weise neben Anwenderprogrammvariablen auch 
direkt Systemzustande und Prozefisignale zu verwenden. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
15 darin, dass die Bedingungen logische und/oder arithmetische 
und/oder beliebige funktionelle Verknupf ungen enthalten. Da- 
mit ist es dem Anwender moglich, innerhalb einer Anweisung 
komplexe Synchronisationsbeziehungen zu spezif izieren . 

20 Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass ein Anwenderprogramm fur den Betrieb der Steue- 
rung mehr als einen solchen Mechanismus en t ha It - Dadurch wer- 
den bei der Programmierung der Anwendungen die Flexibilitat 
und die Moglichkeiten des Anwenders insbesondere hinsichtlich 

25 der Beschreibung von Synchronisationsaktivitaten erhoht. 

\ 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass es mehrere Anwenderprogramme beim Betrieb der 
Steuerung geben kann, die diese Mechanismen enthalten. Da- 
30 durch werden bei der Programmierung der Anwendungen die Fle- 
xibilitat und die Moglichkeiten des Anwenders insbesondere 
hinsichtlich der Beschreibung von Synchronisationsaktivitaten 
erhoht . 

35 Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 

darin, dass der jeweilige Mechanismus einem Anwender in einem 
Anwenderprogramm als iibliches programmiersprachliches Kon- 
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strukt zur Verfugung steht. Der "wait_f or_conclition-Bef ehl" , 
der diesen Mechanismus auslost, kann somit von einem Anwender 
in den Anwenderprogrammen z.B. wie eine while-Schleif e ver- 
wendet werden, wodurch die Programmerstellung sehr erleich- 
5 tert wird. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass das Runtime-System der Steuerung ein Ablaufebe- 
nenmodell enthalt, das mehrere Ablaufebenen unterschiedlichen 
10 Typs mit unterschiedlicher Prioritat aufweist, wobei folgende 
Ablaufebenen vorgesehen sind: 



y a) eine Ebenengruppe mit synchron getakteten Ebenen, beste- 
hend aus mindestens einer Systemebene und mindestens ei- 

15 ner Anwenderebene, wobei die Ebenen dieser Ebenengruppe 

untereinander eine Priorisierung aufweisen konnen, 



b) einer Anwenderebene fur Systemexcept ions 
20 c) einer zeitgesteuerten Anwenderebene 

d) einer ereignisgesteuerten Anwenderebene 



e) einer sequentiellen Anwenderebene 

25 

^ f) einer zyklischen Anwenderebene, 

wobei Anwenderebenen der Ebenengruppe a) optional synchron zu 
einer der Systemebenen der Ebenengruppe a) laufen konnen. Ein 
wesentlicher Vorteil dieser Schichtung liegt darin, dass die 
30 Kommunikation zwischen den Tasks der Prozesssteuerung (SPS) 
und denen der Bewegungssteuerung (MC) minimiert wird. Ein 
weiterer Vorteil liegt darin, dass die Programmierung der 
Steuerungsauf gaben fiir die Prozesssteuerung und fur die Bewe- 
gungssteuerung in einer einheitlichen Programmiersprache mit 
35 einer einheitlichen Erstelloberf lache erfolgen kann und dass 
der Anwender ein fur seine jeweiligen Anf orderungen zuge- 
schnittenes Ablauf ebenenmodell flexibel erstellen kann. 
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Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass der Grundtakt des Ablauf ebenenmodells aus einem 
internen Timer oder aus einem internen Takt eines Kommunika- 
5 tionsmediums oder aus einem externen Gerat oder von einer 

Grofte, die zum technologischen Prozeli gehort abgeleitet wird. 
Dadurch kann sehr flexibel und sehr einfach der Grundtakt fur 
das Ablauf ebenenmodell abgeleitet werden. Dadurch, dass der 
Grundtakt fur das Ablauf ebenenmodell auch von einer Grofte, 
10 die zum technologischen Prozess gehort, ableitbar ist, kann 
auf eine sehr einfache Weise eine direkte Ruckkopplung aus 
dem technologischen Prozess zur Steuerung erhalten werden. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
15 darin, dass die zeitgesteuerte Anwenderebene , die ereignisge- 
steuerte Anwenderebene, die sequentielle Ablaufebene, die 
zyklische Hintergrundebene und die Anwenderebene fur System- 
exceptions optional sind. Der Anwender kann sich dadurch sehr 
flexibel eine Steuerung erstellen, die fur seine konkreten 
20 vorliegenden Anf orderungen sehr effizient ist und die die ge- 
rade benotigten Ablaufebenen enthalt und somit keinen unnoti- 
gen Overhead beinhaltet. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
25 darin, dass die synchronen Ebenen zum Grundtakt iibersetzt 

und/oder untersetzt und/oder im Verhaltnis 1:1 getaktet sind. 

Dadurch konnen die Ebenen jeweils sehr leicht zu einem Viel- 

fachen des Grundtaktes getaktet werden oder aber auch jeweils 

zu einem reziproken Vielfachen getaktet werden. Ausgehend von 
30 einer gemeinsamen Ausgangsgrolie konnen somit sehr einfach U- 

berset zungen, aber auch Untersetzungen fur die jeweiligen E- 

benen erreicht werden . 

35 Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 

darin, dass weitere priorisierende Schichtungen innerhalb der 
Ablaufebenen vorgesehen sind. Die Sof twarestruktur der indus- 
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triellen Steuerung lasst sich dadurch optimal an die unter- 
schiedlichen Steuerungsauf gaben bzw. an die Anf orderungen des 
zugrunde liegenden technischen Prozesses anpassen. Somit las- 
sen sich z.B. unterschiedliche Fehlerursachen unterschiedli- 
5 chen Ebenen mit z.B. auf steigender Prioritat zuordnen. 

Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass optional Anwendertasks beim Systemhochlauf 
und/oder beim Systemrunterf ahren durchlaufbar sind. Dadurch 
10 konnen beim Systemhochlauf z.B. Initialisierungsf unktionen 

angestoflen werden oder beim Systemrunterf ahren wird sicherge- 
stellt, dass die im System vorhandenen Achsen eine definierte 
s > Position einnehmen. 

15 Eine weitere vorteilhafte Ausgestaltung der Erfindung liegt 
darin, dass in die Anwenderebenen Anwenderprogramme ladbar 
sind, die je nach Typ der Anwenderebene zyklusorientiert oder 
sequentiell programmiert sind. Dadurch kann der Anwender in 
seinen Anwenderprogrammen die Funktionalitat der Steuerung 

20 sehr flexibel an die zugrunde liegenden Anf orderungen des 

technischen Prozesses anpassen und er kann auch die Anwender- 
programme in unterschiedliche Anwenderebenen laden, urn da- 
durch eine fur seine jeweiligen Applikationen effektive Aus- 
pragung der Steuerung zu erreichen. Ein weiterer Vorteil 
- 25 liegt darin, dass der Anwender in ein einheitliches Ablauf- 
ebenenmodell bzw. Runtime-System einer industriellen Steue- 
rung sowohl zyklusorientierte Anwenderprogramme als auch er- 
eignisorientierte Anwenderprogramme laden kann. Ein Anwender 
kann somit nach unterschiedlichen Paradigmen programmierte 

30 Programme (zyklusorientiert fur SPS-Funktionalitat und ereig- 
nisorientiert bzw. sequentiell fur Bewegungsf unktionalitat ) 
sehr flexibel und konform in die Anwenderebenen des Ablauf- 
ebenenmodells hinzuladen . 

35 Ein Ausf uhrungsbeispiel der Erfindung ist in der Zeichnung 
dargestellt und wird im folgenden erlautert. 
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Dabei zeigen : 

FIG 1 die wesentlichen Ablaufebenen einer klassischen 

speicherprogrammierbaren Steuerung, 

FIG 2 die wesentlichen Ablaufebenen einer Bewegungssteue- 

rung, 

FIG 3 schematische Darstellung einer industriellen Steue- 

10 rung, 

FIG 4 das Ablauf ebenenmodell der erfindungsgemafien indus- 

(j^v triellen Steuerung, 

15 FIG 5 ein Ausf uhrungsbeispiel fur das Zuladen von Anwen- 

derprogrammen in die Anwenderebenen, 

FIG 6 ein Ausf uhrungsbeispiel fur den Gebrauch und den 

Mechanismus des Wait__f or_Condition-Bef ehls , im Ab- 
20 lauf ebenenmodell der erf indungsgemaften industriel- 

len Steuerung, 

FIG 7 ein weiteres Ausf uhrungsbeispiel fur den Gebrauch 

und den Mechanismus des Wait_f or_Condition-Bef ehls , 
, 25 im Ablauf ebenenmodell der erfindungsgemafien indus- 

triellen Steuerung, 

FIG 8 die syntaktische Beschreibung des 

Wait for Condition-Bef ehls in einem Syntaxdiagramm, 



30 



FIG 9 ein Beispiel fur die Formulierung einer Expression 

in programmiersprachlicher Notation und 



FIG 10 

35 



in einer Schemadarstellung Moglichkeiten, wie der 
Grundtakt fiir die industrielle Steuerung gewonnen 
wird . 
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In der Darstellung gemafi FIG 1 sind die wesentlichen Ablauf- 
ebenen einer klassischen speicherprogrammierbaren Steuerung 
(SPS) , angeordnet nach ihrer Prioritat, gezeigt. Der Priori- 
tatsanstieg ist dabei durch einen Pfeil symbolisiert. In der 
niederpriorsten Ebene werden, wie durch eine gestrichelte Li- 
nie angedeutet, zwei unterschiedliche Auf gaben, namlich ein 
freier Zyklus, d.h. "Anwenderebene freier Zyklus" und eine 
Hintergrund-Systemebene, d.h. "Systemebene Hintergrund" abge- 
wickelt. Der Hintergrund-Systemebene sind z.B. Kommunikati- 
onsauf gaben zugeordnet. Bei einer folgenden Anwenderebene, 
bezeichnet als "Anwenderebene zeitgesteuert", ist der Aufruf- 
takt der Tasks bzw . der Programme dieser Ebene parametrier- 
bar . Es erf olgt eine Uberwachung dahingehend, ob die Bearbei- 
tung eines Anwenderprogrammes dieser getakteten Ebene recht- 
zeitig abgeschlossen ist, bevor das Startereignis erneut auf- 
tritt . Lauf t die Taktzeit ab, ohne dass das Anwenderprogramm 
der zugeordnet en Ebene f ertig abgearbeitet ist, wird eine 
entsprechende Task einer prioritat smafiig ubernachsten "Anwen- 
derebene f iir asynchrone Fehler" gestartet . In dieser "Anwen- 
derebene fur asynchrone Fehler" kann der Anwender die Behand- 
lung von Fehler zustanden ausprogrammieren . 

Auf die "Anwenderebene zeitgesteuert " folgt eine "Anwender- 
ebene Events". Die Reaktion auf externe oder interne Ereig- 
nisse (Events) erf olgt innerhalb der "Anwenderebene Events". 
Ein typisches Beispiel fur ein solches Ereignis ist das 
Schalten eines binaren bzw. digitalen Eingangs, wodurch typi- 
scherweise ein Ereignis ausgelost wird. In einer "Systemebene 
hochprior" liegen die Aufgaben des Betriebssystems , welche 
die Arbeitsweise der programmierbaren Steuerung (SPS) sicher- 
stellen . 

Die Darstellung gemafi FIG 2 zeigt die wesentlichen Ablaufebe- 
nen einer Bewegungssteuerung (MC) . Auch hierbei sind die ein- 
zelnen Ebenen nach ihrer Prioritat hierarchisch, wie durch 
einen Pfeil symbolisiert, angeordnet. Eine "Systemebene Hin- 
tergrund" und eine "Anwenderebene sequentiell" haben eine 
gleiche Prioritat, namlich die niedrigste. Diese aufgabenma- 
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Bige Zugehorigkeit ist wie bei FIG 1 durch eine gestrichelte 
Linie symbolisiert . Die Tasks der "Anwenderebene sequentiell" 
werden zusammen mit den Tasks der "Systemebene Hintergrund" 
im Round-Robin-Verf ahren abgearbeitet . Typische Tasks der 
5 "Systemebene Hintergrund" sind z.B. solche fur Kommunika- 

tionsauf gaben . In der "Anwenderebene sequentiell" laufen die 
vom Anwender programmierten Programmteile fur die eigentliche 
Steuerungsauf gabe . Stolit die Steuerung in einem dieser Pro- 
grammteile auf einen Bewegungs- oder Posit ionierbefehl , wird 

10 ein "Suspend" gesetzt, d.h. das Anwenderprogramm wird an die- 
ser Stelle unterbrochen. In diesem Fall wird ein Befehl syn- 
chron genutzt. Die Abarbeitung dieses Bewegungs- oder Positi- 

M onierbefehls geschieht in einer hochstprioren "Systemebene 

getaktet". Ein jeder Lageregler oder Interpolator, der in der 

15 "Systemebene getaktet" ablauft, fuhrt diesen Bewegungs- bzw. 
Positionierbef ehl aus. Nach Ausfiihrung des Befehls wird in 
die "Anwenderebene sequentiell" zuruckgesprungen und das 
durch "Suspend" unterbrochene Anwenderprogramm wird durch ein 
"Resume" an der gleichen Stelle fortgesetzt. Die "Systemebene 

20 getaktet" ehthalt neben den schon erwahnten Lagereglern auch 
den Interpolationsteil der Steuerung. 

Auf die niederpriorste Ebene setzt die "Anwenderebene Events" 
auf. Hier sind solche Tasks untergebracht , die auf externe 

25 oder interne Ereignisse reagieren. Solche Ereignisse konnen 

I beispielsweise Alarme sein. 

In einer folgenden "Anwenderebene synchrongetaktet " laufen 
synchron getaktete Anwender-Tasks ab, z.B. Regler f unktionali- 
30 taten. Diese Tasks sind synchronisiert zu getakteten System- 
funktionen wie zum Beispiel Interpolator, Lageregler oder 
zyklische Buskommunikation . 

In der Darstellung gemail FIG 3 wird in Form eines Struktur- 
bildes gezeigt, dass die Steuerung eines technischen Prozes- 
35 ses PI liber das Runtime-System RTS einer industriellen Steue- 
rung erfolgt. Die Verbindung zwischen dem Runtime-System RTS 
der Steuerung und dem technischen Prozess PI geschieht bidi- 
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rektional liber die Ein-/Ausgange EA. Die Programmierung der 
Steuerung und damit das Festlegen des Verhaltens des Runtime- 
Systems RTS geschieht im Engineering-System ES . Das Enginee- 
ring-System ES enthalt Werkzeuge fur die Konf igurierung, Pro- 
5 jektierung und Programmierung fur Maschinen bzw. fur die 

Steuerung technischer Prozesse. Die im Engineering-System, er- 
stellten Programme werden uber den Inf ormationspf ad I in das 
Runtime-System RTS der Steuerung ubertragen. Bezuglich seiner 
Hardware-Ausstattung besteht ein Engineering-System ES ubli- 
10 cherweise aus einem Computersystem mit Graphikbildschirm 

(z.B. Display), Eingabehilf smitteln (z.B. Tastatur und Maus) , 
Prozessor, Arbeits- und Sekundarspeicher , einer Einrichtung 
fur die Aufnahme computerlesbarer Medien (z.B. Disketten, 
CDs) sowie Anschlusseinheiten fur einen Datenaustausch mit 
15 anderen Systemen (z.B. weiteren Computersystemen, Steuerungen 
fiir technische Prozesse) oder Medien (z.B. Internet). Eine 
Steuerung besteht ublicherweise aus Eingabe- und Ausgabeein- 
heiten, sowie aus Prozessor und Programmspeicher . Es ist auch 
vorstellbar, dass die Steuerung eines technischen Prozesses 
20 PI uber mehrere Runtime-Systeme RTS von industriellen Steue- 
rungen erfolgt. 

Die Darstellung gemafi FIG 4 zeigt das Ablauf ebenenmodell der 
industriellen Steuerung. Die Priorisierung der Ebenen wird 
25 durch einen Pfeil in Richtung zur hochsten Prioritat angedeu- 
tet. Die niederpriorsten Ebenen sind die "zyklische Anwender- 
ebene" und die "sequentielle Anwenderebene". Diese beiden E- 
benen laufen mit der gleichen Prioritat. Deshalb sind diese 
Ebenen in der Darstellung gemafi FIG 4 durch eine gestrichelte 
30 Linie getrennt. Die "zyklische Anwenderebene" beinhaltet die 
"Background Task", die zykluszeituberwacht ist. In der "se- 
quentiellen Anwenderebene" werden die "Motion Tasks" durch- 
laufen. "Motion Tasks" sind nicht zykluszeituberwacht und 
dienen im Wesentlichen zur Beschreibung sequent ieller Ablau- 
35 fe. "Motion Tasks" werden quasiparallel abgearbeitet . Gene- 
rell enthalten alle Anwenderebenen eine oder mehrere Tasks. 
Die Tasks nehmen die Anwenderprogramme auf. Die Tasks der 
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"zyklische Anwenderebene" und der "sequentiellen Anwenderebe- 
ne" werden in einem gemeinsamen Round-Robin-Zyklus abgearbei- 
tet . 

Die nachstfolgende Ebene ist die "zeitgesteuerte Anwenderebe- 
ne". Die Tasks dieser Ebene werden zeitgesteuert aktiviert. 
Die Zeitsteuerung ist einer Granularitat von Millisekunden 
einstellbar. Auf die "zeitgesteuerte Anwenderebene" folgt die 
"ereignisgesteuerte Anwenderebene". In dieser Ebene werden 
nach Erkennen eines User Interrupts so genannte "User Inter- 
rupt Tasks" aktiviert. User Interrupt Ereigniss.e konnen als 
logische Verkniipfung von Prozessereignissen und/oder internen 
Zustanden formuliert werden. 

Die nachsthohere Ebene ist die "Anwenderebene fur System Ex- 
ceptions". In dieser "Anwenderebene fur System 
Exceptions" werden System Interrupts uberwacht, bei deren 
Eintreffen so genannte "Exceptions", d.h. Ausnahmef allbehand- 
lungen, generiert werden. In der "Anwenderebene fur System 
Exceptions" gibt es z.B. folgende Tasks, die bei Auftreten 
eines entsprechenden System Interrupts aktiviert werden: 

a) "Time Fault Task", die beim Ansprechen von Zeituberwachun- 
gen aktiviert wird, 

b) "Peripheral Fault Task", die z.B. bei Prozess- und Diagno- 
sealarmen aktiviert wird, aber auch bei Stationsausf all o- 
der Stat ions wiederkehr, 

c) "System Fault Task", die bei allgemeinen Systemf ehlern ak- 
tiviert wird, 

d) "Program Fault Task", die bei Programmierf ehlern (z.B. Di- 
vision durch Null) aktiviert wird, 

e) "Time Fault Background Task", die beim Ansprechen der Zyk- 
luszeituberwachung der Background Task aktiviert wird und 
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f) "Technological Fault Task", die bei Technologief ehlern ak- 
tiviert wird. 

5 Als nachstes folgt die Ebenengruppe "synchron getaktete Ebe- 
nen". Diese Ebenengruppe besitzt die hochste Prioritat im Ab- 
lauf ebenenmodell . Die einzelnen Ebenen dieser Ebenengruppe 
konnen untereinander weitere Priorisierungen aufweisen. Die 
Ebenengruppe "synchron getaktete Ebenen" besteht aus mindes- 

0 tens einer Systemebene und mindestens einer Anwenderebene . 

Die Systemebenen beinhalten die Systemf unktionen wie z.B. La- 
geregler oder Interpolator. In die Anwenderebenen dieser Ebe- 
nengruppe konnen von einem Anwender flexibel Anwenderprogram- 
me (API - AP4; FIG 5) zugeladen werden. 

5 

Fur die Taktung der "synchron getakteten Ebenen" gibt es eine 
Reihe unterschiedlicher Taktgenerierungsmoglichkeiten . Der 
Grundtakt kann z.B. aus einem internen Timer (Tl; FIG 10) 
kommen oder aus einem internen Takt (T3; FIG 10) eines Kommu- 

0 nikationsmediums (z.B. Profibus) oder aber der Takt kann auch 
aus einem Prozessereignis des technologischen Prozesses abge- 
leitet werden. Ein solches Prozessereignis kann z.B. die 
Taktrate (TG; FIG 10) eines Vorgangs an einer Produktionsma- 
schine oder Verpackungsmaschine sein. Anwenderebenen der Ebe- 

5 nengruppe "synchron getaktete Ebenen" konnen dabei basierend 
auf dem Grundtakt getaktet werden, sie konnen aber auch syn- 
chron zu einer der Systemebenen der Ebenengruppe "synchron 
getaktete Ebenen" laufen. Die Anwendertasks dieser zu einer 
Systemebene synchronen Anwenderebene haben somit eine syn- 

0 chrone, d.h. deterministische Beziehung zu einer vom Anwender 
flexibel festlegbaren Systemebene. Das hat den Vorteil, dass 
deterministische Reaktionen auf Systemtasks (Systemtasks lau- 
fen in den Systemebenen) , die der Anwender in seinen Anwen- 
dertasks programmiert hat, die in den Anwenderebenen der Ebe- 

5 nengruppe "synchron getaktete Ebenen" laufen, vom System ga- 
rantiert werden. Das heiftt z.B., dass das System garantiert, 
dass diese "synchrone Anwenderebene" entsprechend beispiel- 
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haft vor dem Interpolator aktiviert wird oder aber auch vor 
einer beliebigen anderen Systemf unktion . 

Die "zeitgesteuerte Anwenderebene", die "ereignisgesteuerte 
Anwenderebene" , die "sequentielle Anwenderebene", die "zykli- 
sche Anwenderebene" sowie die "Anwenderebene fur System Ex- 
ceptions" sind optional. 

Die Task der "zyklischen Anwenderebene" (Background Task) ist 
zykluszeituberwacht . Die "Motion Tasks" dagegen sind nicht 
zykluszeituberwacht und dienen im wesentlichen zur Beschrei- 
bung sequentieller Ablaufe. Das heifit, das vorliegende Ab- 
lauf ebenenmodell unterstiitzt einen Anwender sowohl bei der 
Programmierung von sequentiellen Ablaufen als auch bei der 
Ereignisprogrammierung . Es konnen somit synchrone Ereignisse 
als auch asynchrone Ereignisse durch die Programmierung er- 
fasst werden. In die Anwenderebenen sind die vom Anwender er- 
stellten Anwenderprogramme (API - AP4 ; FIG 5) zuladbar. Die 
Anwenderprogramme API bis AP4 werden ublicherweise mit Hilfe 
einer Programmierumgebung des Engineering-Systems (ES; FIG 3) 
erstellt . 

Die Darstellung gemafl FIG 5 zeigt ein Ausf uhrungsbeispiel fur 
das Zuladen von Anwenderprogramm in die Anwenderebenen- FIG 5 
zeigt exemplarisch eine Auspragung von Anwenderebenen des Ab- 
lauf ebenenmodells . Durch die drei Punkte am unteren Rand der 
Zeichnung ist dargestellt, dass auch noch weitere Anwender- 
ebenen, aber auch Systemebenen vorhanden sein konnen. Die 
Priorisierung der Ebenen wird wie im Vorangegangenen durch 
einen Pfeil in Richtung zur hochsten Prioritat angedeutet. 
Den Anwenderebenen werden die Anwenderprogramme API bis AP4, 
am rechten Bildrand durch kleine Rechtecke angedeutet, zuge- 
ordnet. Die Zuordnung wird dargestellt durch Zuordnungspf eile 
ZP1 bis ZP4. In den Anwenderebenen befinden sich Tasks, die 
die zugeladenen Anwenderprogramme API bis AP4 aufnehmen. Die- 
se Tasks werden dann nach einer gewissen Strategie (z.B. se- 
quentiell) durchlaufen bzw. abgearbeitet . Sie konnen weiter- 
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hin die Eigenschaft besitzen, class sie lauf zeitiiberwacht 
sind . 

Die Darstellung gemaft FIG 6 zeigt ein Ausf tihrungsbeispiel fur 
den Gebrauch und den Mechanismus des Wait_f or_Condition- 
Befehls, im Ablauf ebenenmodell der erf indungsgemaften indus- 
triellen Steuerung. Der Wait_f or_Condition-Bef ehl (in FIG 6 
dargestellt als wait_f or_cond ( ) ) wird in dieser Darstellung 
exemplarisch in der "sequentiellen Anwenderebene" verwendet. 
Der Wait_f or_Condition-Bef ehl wird in den vom Anwender er- 
stellten "Motion Tasks" MT1 und MT2 verwendet, die Bestand- 
teil der "sequentiellen Anwenderebene" sind. Die "Motion 
Tasks" MT1 und MT2 hangen in einem Round-Robin-Zyklus , darge- 
stellt durch den Pfeil von MT1 nach MT2 und durch den abge- 
winkelten Pfeil von MT2 zu MT1. Die drei Punkte innerhalb 
dieses Pfeiles deuten an, dass noch weitere "Motion Tasks" im 
Round-Robin-Zyklus hangen konnen. Die "Motion Task" MT1 ent- 
halt den Wait_f or_Condition-Bef ehl "wait_f or_cond (cond_l ) ", 
die "Motion Task" MT2 den Wait_f or-Condition-Bef ehl 
"wait_f or_cond (cond_2 ) " . Jeweils drei Punkte, die innerhalb 
von MT1 bzw. MT2 verwendet werden, deuten an, dass neben den 
beiden Wait_f or_Condition-Bef ehlen und den drei Positionier- 
befehlen posl() bis pos3() noch weitere Befehle in den "Moti- 
on Tasks" enthalten sein konnen. 

Insgesamt besteht das in FIG 6 exemplarisch dargestellte Ab- 
lauf ebenenmodell eines Runtime-Systems fur eine industrielle 
Steuerung aus folgenden Ebenen (aufgezahlt von niedrigster 
bis hochster Prioritat): "zyklische Anwenderebene", "sequen- 
tielle Anwenderebene" (die Tasks dieser beiden Ebenen haben 
die gleiche Prioritat, dargestellt durch die gestrichelte Li- 
nie zwischen diesen Ebenen), " zeitgesteuerte Anwenderebene", 
"ereignisgesteuerte Anwenderebene", "Anwenderebene fur Syste- 
mexceptions" , "synchron getaktete Anwenderebene 2", "syn- 
chron getaktete Anwenderebene 1", "synchron getaktete System- 
ebene 2" und als hochstpriore Ebene eine "synchron getaktete 
Systemebene 1". 



200023219 

16 

Die Arbeitsweise des Wait_f or_Conciition-Bef ehls wird bei- 
spielhaft an "wait_fo'r_cond(cond_l) " aus der "Motion Task" 
MT1 gezeigt. 1st die "Motion Task" MT1 im Round-Robin-Zyklus 
5 an der Reihe, werden die Befehle der "Motion Task" MT1 solan- 
ge bedient, bis die Zeitscheibe abgelaufen ist, oder eine. Un- 
terbrechung kommt . Trifft dies zu, wird die "Motion Task" MT2 
als nachste Task im Zyklus bedient, usw. Wird in der "Motion 
Task" MT1 der wait_f or_cond (cond_l ) -Bef ehl abgearbeitet , wird 
10 die Bedingung cond_l uberprtift. 1st cond_l = true, also er- 

fiillt, dann wird sofort der nachst f olgende Bef ehl pos2() aus- 
gefiihrt und eventuell weitere in MT1 vorhandene Befehle suk- 
zessive abgearbeitet, bis die Kontrolle an die nachste Task 
abgegeben wird. 

15 

1st die Bedingung cond_l = false, also nicht erfullt, wird 
sofort die "Motion Task" MT1 unterbrochen und im Round-Robin- 
Zyklus wird MT2 bedient. Die Bedingung cond_l wird aber in 
die "synchron getaktete Systemebene 2" eingehangt (angedeutet 

20 durch den durchgehenden abgewinkelten Pfeil vom 

wait_f or_cond (cond_l) -Bef ehl zu der "synchron getakteten Sys- 
temebene 2") und im Takt dieser Systemebene auf ihr Erfullt- 
sein iiberpruft. 1st die Bedingung cond_l erfullt, wird im 
Round-Robin-Zyklus die aktuelle Task verdrangt, d.h. ihr wird 
t 25 die Zeitscheibe entzogen und die Motion Task MT1 wird sofort 
unmittelbar nach dem wait_f or_cond (cond_l ) mit dem Positio- 
nierbefehl pos2() fortgesetzt. Durch den gestrichelten Pfeil 
wird der Rucksprung aus der "synchron getakteten Systemebene 
2" zum Positionierbef ehl pos2(), d.h. zur " sequentiellen An- 

30 wenderebene" angedeutet. 

Dadurch, dass bei Nichterf ulltsein der Bedingung des 
Wait__f or_Condition-Bef ehls die Oberprufung der Bedingung in 
einer hochprioren "synchron getakteten Systemebene" stattfin- 
35 det, und bei Erfiilltsein der Bedingung sofort die unterbro- 
chene "Motion Task" fortgesetzt wird, ist es einem Anwender 
moglich, bei der Programmierung von Bewegungssequenzen extrem 
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zeitkritische Applikationen mit einfachen Sprachmitteln zu 
spezif izieren. Die Performance und Determinist ik wird noch 
dadurch erhoht, dass beim Uberprufen der Bedingungen in den 
jeweiligen hochprioren "synchron getakteten Systemebenen" nur 
aktuell anstehende Bedingungen eingehangt und berucksichtigt 
werden. 

Der hier beschriebene Mechanismus erfordert auch keinen ex- 
pliziten Event-Handler. Der grofie Vorteil aus Anwendersicht 
liegt somit darin, dass der Anwender jetzt in einem sequen- 
tiellen Ablauf programm auf einer relativ niedrigen Priori- 
tatsebene einer "Motion Task" in seinem Programmf luss 
hochpriore Ereignisse mit Hilfe von Programmkonstrukten for- 
mulieren kann und nicht in ein anderes Programm wechseln 
muss, das er dann uber andere Mechanismen (z.B. per Hand oder 
interruptgesteuert ) auf synchrone Anwendertask abbilden muss, 
sondern er hat die Moglichkeit, in einem geschlossenen Anwen- 
derprogramm diesen Zyklus "Warten auf hochpriores Ereignis" 
und "hochpriore Reaktion" auf dieses Ereignis in einem Pro- 
gramm geschlossen zu formulieren. 

Die Bedingungen, die in einem Wait_f or_Condition-Bef ehl abge- 
fragt werden, konnen vom Anwender sehr flexibel und elegant 
formuliert werden. So kann der Anwender zur Formulierung die- 
ser Bedingungen Programmvariablen aus einem Anwenderprogramm 
verwenden oder interne Groften der Steuerung oder er kann auch 
Prozesssignale ref erenzieren . Diese Grolien konnen dann lo- 
gisch, arithmetisch oder mit beliebigen Funktionen inhaltlich 
verknupft werden, urn daraus eine Bedingung zu formulieren. 
Neben dem hochprioren Abfragen, ob die Bedingung erfullt ist, 
kann man sich auch vorstellen, dass bei Erfulltsein der Be- 
dingung auch noch dazugehoriger Programmcode, d.h. eine da- 
hinterliegende Reaktion, die anwenderprogrammierbar ist, 
hochprior ausgefiihrt wird. Und dass erst nach der Ausfuhrung 
dieses Programmcodes der Riicksprung in die niederpriore Ebene 
erf olgt . 
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Die Darstellung gemaft FIG 7 zeigt ein erweitertes Ausfiih- 
rungsbeispiel fiir den Gebrauch und den Mechanismus des 
Wait_f or_Condition-Bef ehls, im Ablauf ebenenmodell der erfin- 
dungsgemalien industriellen Steuerung. Der Wait_f or_Condition- 
5 Befehl (in FIG 7 ebenfalls dargestellt als wait_for_cond() ) 

wird in dieser Darstellung exemplarisch in der "sequentiellen 
Anwenderebene" verwendet. Der Wait__f or_Condition-Bef ehl wird 
in den vom Anwender erstellten "Motion Tasks" MT3 und MT4 
verwendet, die Bestandteil der "sequentiellen Anwenderebene" 
10 sind. Die "Motion Tasks" MT3 und MT4 hangen in einem Round- 
Robin-Zyklus, dargestellt durch den Pfeil von MT3 nach MT4 
und durch den abgewinkelten Pfeil von MT4 zu MT3. Die drei 
^ Punkte innerhalb dieses Pfeiles deuten an, dass noch weitere 
"Motion Tasks" im Round-Robin-Zyklus hangen konnen. Die "Mo- 
15 tion Task" MT3 enthalt den Wait_f or__Condition-Bef ehl 

"wait_f or_cond (cond_3) " , die "Motion Task" MT4 den Wait_for- 
Condition-Bef ehl "wait_f or_cond (cond__4 ) " . Jeweils drei Punk- 
te, die innerhalb von MT3 bzw. MT4 verwendet werden, deuten 
an, dass neben den beiden Wait_for_Condition-Bef ehlen und den 
20 Positionierbef ehlen pos4() bis pos8() noch weitere Befehle in 
den "Motion Tasks" enthalten sein konnen. Durch die program- 
miersprachlichen Konstrukte "wait_f or_cond ( ) " und 
"end_wait_f or_cond" wird eine Programmsequenz in den "Motion 
Tasks" geklammert . In der "Motion Task" MT3 sind die Befehle 
^25 pos5() und pos6() auf diese Weise geklammert- Auch in der 
™ "Motion Task" MT4 wird die Verwendung von "wait_f or_cond ( ) " 
und "end_wait_f or_cond" angedeutet. Durch jeweils 3 Punkte 
ist in der "Motion Task" MT4 skizziert, dass vor, innerhalb 
und nach dem "wait_f or_cond ( ) - end_wait_f or_cond"-Konstrukt 
30 weitere Anweisungen vorhanden sein konnen. 

Das in FIG 7 exemplarisch dargestellte Ablauf ebenenmodell ei- 
nes Runtime-Systems fiir eine industrielle Steuerung besteht 
wie in FIG 6 aus folgenden Ebenen (aufgezahlt von niedrigster 
35 bis hochster Prioritat): "zyklische Hintergrundebene" , "se- 

quentielle Anwenderebene" (die Tasks dieser beiden Ebenen ha- 
ben die gleiche Prioritat, dargestellt durch die gestrichelte 
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Linie zwischen diesen Ebenen) , "ereignisgesteuerte Anwender- 
ebene", " zeitgesteuerte Anwenderebene", "Anwenderebene fur 
Systemexceptions", "synchron getaktete Anwenderebene 2", 
"synchron getaktete Anwenderebene 1", "synchron getaktete 
5 Systemebene 2" und als hochstpriore Ebene eine "synchron ge- 
taktete Systemebene 1". 

In FIG 7. wird die Arbeitsweise des Wait_f or_Condition-Bef ehls 
mit einer dazugehorigen Programmsequenz gezeigt beispielhaft 

10 an "wait_f or_cond (cond_3) " aus der "Motion Task" MT3 gezeigt. 
Das Uberpriifen der Bedingung cond_3 und das Abarbeiten der 
dazugehorigen Programmsequenz (geklammert zwischen 
| "wait__f or_cond (cond_3) " und "end_wait_f or_cond" ) erfolgen da- 
bei auf einer hoherprioren Ebene des Ablauf ebenenmodells . Die 

15 zu "wait__f or__cond (cond_3 ) " dazugehorigen Programmsequenz wird 
durch die Abfolge der Befehle pos5() und pos6() gebildet. 

1st die "Motion Task" MT3 im Round-Robin-Zyklus an der Reihe, 
werden die Befehle der "Motion Task" MT3 solange bedient, bis 
20 die Zeitscheibe abgelaufen ist, oder eine Unterbrechung 

kommt. Trifft dies zu, wird die "Motion Task" MT4 als nachste 
Task im Zyklus bedient, usw. Wird in der "Motion Task" MT3 
der "wait_f or_cond (cond_3) "-Bef ehl abgearbeitet , so wird die 
Bedingung cond_3 tiberpruft. Ist cond_3 = true, also erfullt, 
25 dann wird der normale programmablauf fortgesetzt, d.h. als 
^ nachstes wird der Bef ehl pos5() ausgefuhrt und eventuell wei- 
tere in MT3 vorhandene Befehle sukzessive abgearbeitet, bis 
die Kontrolle an die nachste Motion Task abgegeben wird. 

30 Ist die Bedingung cond_3 = false, also nicht erfullt, wird 

sofort die "Motion Task" MT3 unterbrochen und im Round-Robin- 
Zyklus wird MT4 bedient. Die Bedingung cond_3 und die Befehle 
pos5() und pos6() (als dazugehorige Programmsequenz) werden 
in der Prioritat der "synchron getakteten Systemebene 2" be- 

35 arbeitet (angedeutet durch den durchgehenden abgewinkelten 

Pfeil, ausgehend von der Klammer, die die Zusammengehorigkeit 
von wait_f or_cond (cond_3 ) , end_wait_f or_cond und dazugehori- 
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ger Programmsequenz ausdruckt, hin zu der "synchron getakte- 
ten Systemebene 2"). Im Takt dieser Systemebene wird cond__3 
auf ihr Erfulltsein uberpruf t . 1st die Bedingung cond_3 er- 
fiillt, wird mit der Prioritat der "synchron getakteten Sys- 
5 temebene 2" die dazugehorige Programmsequenz (hier: die Ab- 
folge der Befehle pos5() und pos6() abgearbeitet . Durch den 
gestrichelten Pfeil wird der Riicksprung aus der "synchron ge- 
takteten Systemebene 2" zum Positionierbef ehl pos7(), d.h. 
zur " sequentiellen Anwenderebene" angedeutet. 

10 

Dadurch, dass bei Nichterf iilltsein der Bedingung des 
Wait__f or_Condition-Bef ehls die Uberprufung der Bedingung in 

| einer hochprioren "synchron getakteten Systemebene" stattfin- 
det, und bei Erfulltsein der Bedingung sofort eine dazugehd- 

15 rige, vom Anwender erstellbare Programmsequenz auf dieser 

hochprioren Systemebene ausgefiihrt wird, konnen sogar extrem 
zeit kritische Applikationen mit einfachen Sprachmitteln spe- 
zifiziert und durchgefuhrt werden. 

20 Ein moglicher Anwendungsf all ist die Druckmarkensynchronisa- 
tion. Dabei geht es darum, eine Druckmarke auf einem Material 
hochprior zu erkennen. Beim Erkennen dieser Druckmarke wird 
typischerweise ein Istwert erfasst ("Latchen" z.B. eines La- 
ge- oder Geberistwertes) . Ausgehend von diesem erfassten Ist- 

25 wert wird ein Korrekturwert berechnet, der dem System als u- 
berlagerte Bewegung aufgepragt wird. Der Vorgang Istwert- 
Erkennung, Korrekturwert-Berechnung und Durchfuhrung der u- 
berlagerten Bewegung muli in einer deterministischen Zeitdauer 
erfolgen. Deswegen mufi dieser Vorgang hochprior stattfinden. 

30 

Ein weiterer Anwendungsf all ist der "schnelle Bewegungs- 
start". Hier geht es darum, z.B. Flankenwechsel sehr schnell 
zu erkennen und daran sofort anschlieftend einen Bewegungs- 
start (z.B. Positionierbewegung) zu beginnen. Die Determinis- 
35 tik Erkennen eines Ereignisses und Auslosen von Folgeakt ionen 
ist entscheidend fur die Produktivitat einer Maschine. Bei 
Produktionsmaschinen mussen solche zyklischen Vorgange in ei- 
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ner deterministischen Zeit, z.B. <100 ms oder <50 ms erfol- 
gen. Beim Abarbeiten der Tasks auf einer normalen Hinter- 
grundebene kann diese Deterministik nicht garantiert werden. 
Der beschriebene Mechanismus ist besonders fur einen Einsatz 
5 bei Maschinen geeignet, die periodische Maschinenzyklen auf- 
weisen. 



Die Performance wird noch dadurch erhoht, dass beim Oberpru- 
fen der Bedingungen in den jeweiligen hochprioren "synchron 
10 getakteten Systemebenen" nur aktuell anstehende Bedingungen 
eingehangt und beriicksichtigt werden. 

^ Der hier beschriebene Mechanismus erfordert, wie schon in FIG 
6 erwahnt, keinen expliziten Event-Handler. Der grofle Vorteil 

15 aus Anwendersicht liegt somit darin, dass der Anwender jetzt 
in einem sequentiellen Ablauf programm auf einer relativ nied- 
rigen Prioritat sebene einer "Motion Task" in seinem Programm- 
fluss hochpriore Ereignisse mit Hilfe von Programmkonstrukten 
formulieren kann und nicht in ein anderes Programm wechseln 

20 muss, das er dann uber andere Mechanismen (z.B. per Hand oder 
interruptgesteuert ) auf synchrone Anwendertask abbilden muss, 
sondern er hat die Moglichkeit, in einem geschlossenen Anwen- 
derprogramm diesen Zyklus "Warten auf hochpriores Ereignis" 
und "hochpriore Reaktion" auf dieses Ereignis in einem Pro- 

25 gramm geschlossen zu formulieren. 

Der Wait_f or_Condition-Bef ehl kann vom Anwender sehr flexibel 
und einfach eingesetzt werden, da er als normales program- 
miersprachliches Konstrukt zur Verfugung steht. Auch die For- 

30 mulierung der Bedingungen ist fur einen Anwender flexibel und 
einfach. So kann der Anwender zur Formulierung dieser Bedin- 
gungen Programmvariablen aus einem Anwenderprogramm verwenden 
oder interne Grolien der Steuerung oder er kann auch Prozess- 
signale ref erenzieren . Diese Grolien konnen dann logisch, a- 

35 rithmetisch oder mit beliebigen Funktionen inhaltlich ver- 
knupft werden, urn daraus eine Bedingung zu formulieren. 
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Durch clas Wait_f or_Condition-Konstrukt hat ein Anwender die 
Moglichkeit in normalen Anwenderprogrammen fur Bewegungsse- 
quenzen, ein Anwenderprogramm temporar auf eine hohere Prio- 
ritatsebene zu legen, um deterministische Vorgange garantie- 
5 ren zu konnen. 

Darstellung gemaft FIG 8 zeigt das programmiersprachliche Kon- 
strukt des wait_f or_condition-Mechanismus als Syntaxdiagramm. 
Die terminalen Elemente sind dabei mit abgerundeten Ecken 
10 dargestellt : "WAITFORCONDITION" , "WITH" , " DO" , 

"END_WAITFORCONDITION" und " ; " . Als Rechtecke sind die nicht- 
terminalen Elemente dargestellt: "Expressions-Bezeichnung, 
"SCHALTER" und "ANWEISUNGSTEIL" . Die Elemente "WITH" und 
"SCHALTER" sind optional. 

15 

Darstellung gemafl FIG 9 zeigt die Verwendung des 
Wait_f or_Condition-Konstruktes in einem Programmablauf . Im 
oberen Teil von FIG 9 ist die Formulierung der Bedingung "my- 
Expression" dargestellt, im unteren Teil ist gargestellt, wie 
20 diese Bedingung in einem Wait_f or_Condition-Konstrukt verwen- 
det wird. 

Darstellung gemafi FIG 10 zeigt in einer Schemadarstellung 
Moglichkeiten, wie der Grundtakt fur die industrielle Steue- 
( ; ,25 rung gewonnen wird- FIG 10 zeigt exemplarisch eine Kommunika- 
W tionstopologie, in die die Steuerung S integriert ist- Die 
Steuerung S ist durch ein Rechteck dargestellt- Durch eine 
Anschlussleitung A2 ist die Steuerung S mit dem Bus Bl ver- 
bunden, an dem uber eine Anschlussleitung Al das externe Ge- 
30 rat EG hangt . Ober den Bus B2 erfolgt die Verbindung zum 

technischen Prozess P2 - Der technische Prozess P2 ist am un- 
teren Bildrand durch ein Rechteck dargestellt. Ober die An- 
schlussleitung A3 ist die Steuerung S mit dem Bus B2 verbun- 
den, der wiederum liber die Anschlussleitung A4 die Verbindung 
35 zum technischen Prozess P2 herstellt. 
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Die Generierung fur den Grundtakt der Steuerung S kann aus 
unterschiedlichen Taktquellen erfolgen. So z.B. aus einer in- 
ternen Taktquelle, dargestellt durch den internen Timer T2 
der Steuerung S oder auch durch eine externe Taktquelle wie 
5 z.B. den Timer Tl, der zum externen Gerat EG gehort . Als ex- 
terne Taktquelle kann aber auch der Grundtakt eines Kommuni- 
kationsmediums dienen. Wenn der Bus B2 z.B. durch einen aqui- 
distanten Profibus realisiert wird, dann kann der Takt fur 
die Steuerung aus dem Grundtakt dieses Busses gewonnen wer- 

10 den. In FIG 10 ist dies dargestellt dadurch, dass der Timer 
T3 direkt an der Anschlussleitung A3 positioniert ist, und 
diese Anschlussleitung A3 stellt die Verbindung zum Bus B2 

f her. Die Steuerung hangt somit als Slave am Bus und kann di- 
rekt den Bustakt verwenden. Weiterhin kann als externe Takt- 

15 quelle ein Taktgeber TG dienen, der im technischen Prozess P2 
integriert ist. Ein Taktgeber TG in einem technischen Prozess 
kann z.B. der Arbeitstakt einer Produktionsmaschine oder Ver- 
packungsmaschine sein. In der Darstellung gemaft FIG 10 sind 
als Kommunikationsmedien beispielhaft Busverbindungen darge- 

20 stellt. Es konnen aber als Kommunikationsmedien aber auch 
Ring-, Stern- oder andere Verbindungsarten gewahlt werden, 
auch wireless-Verbindungen . Aus diesen Verbindungssystemen 
kann dann der oben genannte Grundtakt abgeleitet werden . 
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Patentanspruche 



1. Verfahren zum Betrieb einer industriellen, mit einem Run- 
time-System (RTS) ausgestatteten Steuerung (S) , insbesondere 
5 fur Produktionsmaschinen, 

dadurch gekennzeichnet, 

dass Mechanismen bereitgestellt sind, die es einem Anwender 
ermoglichen im Programmf luB auf eine beliebige Bedingung zu 
warten, wobei bei Erfulltsein der Bedingung der Programmf lufi 

10 unmittelbar fortgesetzt wird, bei Nichterf iilltsein der Bedin- 
gung der Programmfluft solange angehalten wird, bis das Er- 
fulltsein der Bedingung festgestellt wird, wobei beim Warten 
If auf das Erfulltsein der Bedingung die Prioritat der Bedin- 

gungsuberpruf ung im Vergleich zur aktuellen Taskprioritat er- 

15 hoht wird. 



2. Industrielle Steuerung nach Anspruch 1, 
dadurch gekennzeichnet, 

dass nach dem Erfulltsein der Bedingung die folgende Pro- 
20 grammsequenz bis zu einem expliziten Ende hochprior bearbei- 
tet wird, wobei nach dem expliziten Ende der Programmsequenz 
die alte Taskprioritat wieder aufgenommen wird. 

3. Industrielle Steuerung nach Anspruch 1 oder 2, 
25 dadurch gekennzeichnet, 

* dass fur die Formulierung der Bedingungen ProzeBsignale 

und/oder interne Signale der Steuerung und/oder Variablen aus 
Anwenderprogrammen (API - AP4) verwendet werden. 

30 4. Industrielle Steuerung nach einem der vorstehenden Anspru- 
che, 

dadurch gekennzeichnet, 

dass die Bedingungen logische und/oder arithmetische und/oder 
beliebige funktionelle Ver kniipf ungen enthalten. 



35 
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5. Industrielle Steuerung nach einem der vorstehenden Ansprii 
che, 

dadurch gekennzeichnet, 
dass ein Anwenderprogramm (API - AP4 ) fur den Betrieb der 
5 Steuerung mehr als einen solchen Mechanismus enthalt. 

6. Industrielle Steuerung nach einem der vorstehenden Ansprii 
che, 

dadurch gekennzeichnet, 
10 dass es mehrere Anwenderprogramme (API - AP4) beim Betrieb 
der Steuerung geben kann, die diese Mechanismen enthalten. 



7. Industrielle Steuerung nach einem der vorstehenden Ansprii 
che, 

15 dadurch gekennzeichnet, 

dass der jeweilige Mechanismus einem Anwender in einem Anwen 
derprogramm (API - AP4 ) als ubliches programmiersprachliches 
Konstrukt zur Verfiigung steht. 

20 8. Industrielle Steuerung zur Durchfuhrung des Verfahrens 
nach einem der vorstehenden Anspriiche, 
dadurch gekennzeichnet, 
dass das Runtime-System (RTS) der Steuerung (S) ein Ablauf- 
ebenenmodell enthalt, das mehrere Ablaufebenen unterschiedli 

25 chen Typs mit unterschiedlicher Prioritat aufweist, wobei 
T folgende Ablaufebenen vorgesehen sind: 

a) eine Ebenengruppe mit synchron getakteten Ebenen, beste- 
hend aus mindestens einer Systemebene und mindestens ei- 

30 ner Anwenderebene, wobei die Ebenen dieser Ebenengruppe 

untereinander eine Priorisierung aufweisen konnen, 

b) einer Anwenderebene fur Systemexceptions, 
35 c) einer zeitgesteuerten Anwenderebene 



d) einer ereignisgesteuerten Anwenderebene 
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e) einer sequentiellen Anwenderebene 

f) einer zyklischen Anwenderebene, 

5 wobei Anwenderebenen der Ebenengruppe a) optional synchron zu 
einer der Systemebenen der Ebenengruppe a) laufen konnen.. 

9. Industrielle Steuerung nach Anspruch 8, 
dadurch gekennzeichnet, 

10 dass der Grundtakt des Ablauf ebenenmodells aus einem internen 
Timer (T2) oder aus einem internen Takt (T3) eines Kommunika- 
tionsmediums oder aus einem externen Gerat (EG) oder von ei- 

l ner Grofte (TG) , die zum technologischen Prozeft (PI, P2) ge- 
hort abgeleitet wird. 

15 

10. Industrielle Steuerung nach Anspruch 8 oder Anspruch 9, 
dadurch gekennzeichnet, 

dass die zeitgesteuerte Anwenderebene, die ereignisgesteuerte 
Anwenderebene, die sequentielle Ablaufebene, die zyklische 
20 Hintergrundebene und die Anwenderebene fur Systemexceptions 
optional sind . 

11. Industrielle Steuerung nach Anspruch 8, 9 oder 10, 
dadurch gekennzeichnet, 

25 dass die synchronen Ebenen zum Grundtakt ubersetzt und/oder 
^ untersetzt und/oder im Verhaltnis 1:1 getaktet sind. 

12. Industrielle Steuerung nach Anspruch 8, 9, 10 oder 11, 
dadurch gekennzeichnet, 

30 dass weitere priorisierende Schichtungen innerhalb der Ab- 
lauf ebenen vorgesehen sind . 

13. Industrielle Steuerung nach Anspruch 8, 9, 10, 11 oder 
12, 

35 dadurch gekennzeichnet, 

dass optional Anwendertasks beim Systemhochlauf und/oder beim 
Systemrunterf ahren durchlauf bar sind. 
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14. Industrielle Steuerung nach Anspruch 8, 9, 10, 11, 12 o- 
der 13, 

dadurch gekennzeichnet, 

dass in die Anwenderebenen Anwenderprogramme (API - AP4) lad- 
5 bar sind, die je nach Typ der Anwenderebene zyklusorientiert 
oder sequentiell programmiert sind. 



10 
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Zusammenf as sung 

Verfahren zum Betrieb einer industriellen Steuerung 

5 Es werden Mechanismen zum Betrieb einer industriellen, mit 

einem Runtime-System (RTS) ausgestatteten Steuerung (S), ins- 
besondere fur Produkt ionsmaschinen bereitgestellt sind, die 
es einem Anwender ermoglichen im Programmf luss auf eine be- 
liebige Bedingung zu warten, wobei bei Erfulltsein der Bedin- 

10 gung der Programmf luss unmittelbar fortgesetzt wird, bei 

Nichterf ulltsein der Bedingung der Programmf luss solange an- 
gehalten wird, bis das Erfulltsein der Bedingung festgestellt 
1 wird, wobei beim Warten auf das Erfulltsein der Bedingung die 
Prioritat der Bedingungsiiberpruf ung im Vergleich zur aktuel- 

15 len Taskprioritat erhoht wird. Bei Erfulltsein der Bedingung 
wird eine definierte Programmsequenz bis zu einem expliziten 
Ende hochprior bearbeitet wird, wobei nach dem expliziten En- 
de der Programmsequenz die alte Taskprioritat wieder aufge- 
nommen wird. 

20 

FIG 6 
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Systemebene hochprior 



Anwenderebene fur asynchrone Fehler 



Anwenderebene Events 



Anwenderebene zeitgesteuert 



Anwenderebene freier Zyklus 
Systemebene Hintergrund 
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FIG1 



Systemebene getaktet 



Anwenderebene synchrongetaktet 



Anwenderebene Events 



Anwenderebene sequentiell 
Systemebene Hintergrund 



FIG 2 
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RTS 
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Synchron getaktete Ebenen 
Anwenderebene fur Systemexceptions 
ereignisgesteuerte Anwenderebene 
zeitgesteuerte Anwenderebene 



sequentielle Anwenderebene 
zyklische Anwenderebene 



FIG 4 



synchron getaktete Anwenderebene 1 
synchron getaktete Anwenderebene 2 
synchron getaktete Anwenderebene 3 
synchron getaktete Anwenderebene 4 
ereignisgesteuerte Anwenderebene 
zeitgesteuerte Anwenderebene 



FIG 5 
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synchron getaktete 
Systemebene 1 



synchron getaktete 
Systemebene 2 



synchron getaktete 
Anwenderebene 1 



synchron getaktete 
Anwenderebene 2 



Anwenderebene fur 
Systemexceptions 



ereignisgesteuerte 
Anwenderebene 



zeitgesteuerte 
Anwenderebene 



Sequentielle Anwenderebene 

MT1 




r 



MT2 



pos 3 ( ) 

wait_for_cond(cond_2) 



zyklische Anwenderebene 



FIG 6 
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synchron getaktete 
Systemebene 1 



synchron getaktete 
Systemebene 2 



synchron getaktete 
Anwenderebene 1 



synchron getaktete 
Anwenderebene 2 



Anwenderebene fur 
Systemexceptions 



ereignisgesteuerte 
Anwenderebene 



zeitgesteuerte 
Anwenderebene 



Sequentielle Anwenderebene 



r 



MT3 



pos 4 ( ) 

wait_for_cond(cond_3) 
pos 5 ( ) 
pos 6 ( ) 

end_wait_for_cond 
pos7() 



r 



MT4 



pos 8 ( ) 

wait_for_cond(cond_4) 
end wait for cond 
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zyklische Anwenderebene 



FIG 7 
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WAITFORCONDITION 



Expressions- 
Bezeichnung 



-(with)- 



SCHALTER 



Kh°> 



Anweisungsteil 



END WAITFORCONDITION 



IMPLEMENTATION 



FIG 8 



EXPRESSION myExpression 

//Vereinbarung lokaler Variablen moglich 
VAR 

myLoc : WORD 
END_VAR 

myLoc :=%IW10 & 16#ff00; 

//Dies ist eine mit WAITFORCONDITION auszuwertende 
//Bedingung (Rtickgabewert der Funktion) . Wenn FALSE, 
//wird die betreffende Task ausgesetzt, bis Bedingung 
//TRUE ergibt. 

myExpression :=myloc <> 16#0100; 
END EXPRESSION 



PROGRAM myProgram 

//Aufruf des Befehls mit Namen der Expression 
WAITFORCONDITION myExpression WITH TRUE DO 
// hier mind, eine Anweisung, wird hochprior ausgefuhrt 
END_WAI T FORCOND I T I ON ; 

END_PROGRAM 
END IMPLEMENTATION 



FIG 9 



